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Abstract 

This paper describes the design and implementation of GridCertLib, a Java library 
leveraging a Shibboleth-based authentication infrastructure and the SLCS online cer- 
tificate signing service, to provide short-lived X.509 certificates and Grid proxies. 

The main use case envisioned for GridCertLib, is to provide seamless and secure 
access to Grid X.509 certificates and proxies in web applications and portals: when a 
user logs in to the portal using SAML-based Shibboleth authentication, GridCertLib 
uses the SAML assertion to obtain a Grid X.509 certificate from the SLCS service and 
generate a VOMS proxy from it. 

We give an overview of the architecture of GridCertLib and briefly describe its pro- 
gramming model. Its application to some deployment scenarios is outlined, as well as 
a report on practical experience integrating GridCertLib into portals for Bioinformat- 
ics and Computational Chemistry applications, based on the popular P-GRADE and 
Django softwares. 



1 Introduction 



Most Grid computing middleware in production use today relies on X.509 certificate 
proxies [44) for user authentication. This has been an issue when implementing web- 
based interfaces to Grid computing facilities: in order to generate a proxy, a copy of the 
X.509 private key is needed together with the passphrase used to encrypt it. However, 
uploading the public/private key pair to a web portal is undesirable on security grounds. 
Several solutions and workarounds have been implemented (see Section |2]below), but 
none of them can be considered entirely satisfactory: either because they do not fully 
address the security concerns, or because they require end users to take multiple steps, 
possibly through different and unrelated user interfaces (e.g. a web portal and UNIX 
shell commands). 
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The solution we developed leverages two features offered by SWITCH: the feder- 
ated authentication and authorization infrastructure SWITCHaai and the Short-Lived 
Credential Service OSLCSD . SWITCHaai is a federated authentication and authoriza- 
tion infrastructure |40|, based on Shibboleth2 [18|; SWITCHaai federates all Univer- 
sities in Switzerland, plus major research centers and educational institutions. Similar 
nationwide Authentication and Authorization Infrastructures ( lAAlfc ) exist in Germany, 
Denmark, Belgium, the Netherlands and other countries [7 |. A web service provider 
(e.g., a portal) requiring SWITCHaai authentication will delegate the authentication 
step to the user's home institution Identity Provider (HdPD . Users will be prompted 
with the familiar login page of the home institution; after successful logon, the service 
provider will receive a set of parameters and additional metadata (about the user) to 
proceed with authorization [39]. 

SWITCH also provides the Short-Lived Credential Service (ISLCSD and makes it 
available to all SWITCHaai users 071 . ISLCSl is a web-service that can sign an X.509 
certificate online; authentication and authorization to the ISLCSI service are based on 
the SWITCHaai Shibboleth system. The online Certification Authority ( ICAD that signs 
ISLCSI certificates is included in the International Grid Trust Federation OIGTFD bundle 
ifTTl . so lSLCSI certificates can be used for any legitimate Grid purpose. This enables any 
user from a Swiss institution participating in the SWITCHaai Federation to request 
a Grid-enabled X.509 certificate. It is valid up to 1' 000' 000 seconds (corresponding 
to almost 1 1 days) which is short-lived in comparison to regular one-year certificates 
issued by other CAs. A lSLCSI command-line client is also part of the gLite middleware 
distribution [43 1. 

The last key enabler for our project is the Shibboleth delegation feature, devel- 
oped in the Shibboleth uPortal project [5]. The delegation is based on the Liberty 
IIP- WSFIECPl Single Sign-On ( tssob profile US, and allows SAML-based authentication 
for Shibboleth-protected web service providersQBased on the assertion resulting from 
the web authentication through Shibboleth on the user portal, we are able to call the 
ISLCSI service on the user's behalf using the Enhanced Client or Proxy ( IECPD profile. 
Delegation, however, is still an experimental feature in Shibboleth, and is expected to 
become standard in the next Shibboleth version 3.0. For our project, SWITCH has 
upgraded their Shibboleth Virtual Home Organization identity provider and the ISLCSI 
service provider with lECPI delegation features. 

GridCertLib is a Java library providing programming interfaces to create a ISLCSI 
certificate and Grid proxy (optionally IVOMSI -enabled). given the Security Assertion 
Markup Language OSAMLD assertion resulting from a successful previous Shibboleth 
authentication. The main use case envisioned for GridCertLib, is to provide seam- 
less and secure access to Grid X.509 certificates and proxies in web portals: when 
a user logs in to the portal using the regular SWITCHaai Shibboleth authentication, 
GridCertLib uses the ISAMLl assertion to obtain a Grid X.509 certificate from the ISLCSI 
service and generate a Virtual Organisation Membership Service OVOMSD proxy from 
it. None of these steps requires user interaction (after the initial Shibboleth authentica- 
tion), making Grid resources as easy to use as any single-sign-on enabled web service 
while retaining the full security stack. 

The outline of the paper is as follows: first we provide an overview of similar solu- 
tions already implemented in production-grade Grid web portals. In the next Section, 
we review the requirements that were set for GridCertLib, its actual design and discuss 
some implementation details. Finally, we report on some deployment scenarios and 

'The interested reader can find readable introductions to Shibboleth and lSAMLl in I19II15I . 
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particularly on the integration of GridCertLib within a Bionformatics portal (based on 
P-GRADE, ifTOl ) and within a Computational Chemistry portal (based on Django, 1 8 1). 

2 An overview of existing solutions 

Distributed authentication and authorization is a difficult problem to solve in a stan- 
dard and integrated manner. In past Grid projects, proprietary services have often been 
developed to address this issue (e.g. CAS[34|, PRIMA[27|, ROAMS) but none of 
them established itself as a widely accepted community standard as they were too 
tightly coupled with the middleware and the local resources. A standardization on 
ISAMUXACMLI profiles to be used by all middlewares is available ifTTl but has not been 
widely adopted yet. 

However, we can see two technologies that are widely accepted also outside of the 
Grid community: ISAMU based authentication using Shibboleth and X.509 certificates 
to authenticate local resources, using short-lived proxy certificates. In most Grids, also 
the IVOMSl cervice is used to enrich the proxy certificate with usage attributes for fine- 
grained authorization. We are using the ISLCSI service as developed by SWITCH for 
the Enabling Grids for E-sciencE (IEGEED consortium to generate certificates from the 
users' Shibboleth login. A similar but now defunct project was the U.S. GridShib effort 
[4 1 to create a certificate based on a Shibboleth login also as a Certificate Authority. 

In order to generate a certificate proxy, a copy of the X.509 private key is needed 
together with the passphrase used to encrypt it. This poses a basic problem in web 
portals: having direct access to the public/private certificate key pair of a user, although 
technically feasible, is undesirable on security grounds: intruders getting access to the 
portal machine would gain unrestricted access to all of the portal users' credentials. 

Some projects have worked around this issue by submitting to the Grid as a single 
portal superuser, using credentials of a single entity for all Grid jobs issued through the 
portal or through special-purpose certificates for automation, called "robot" certificates. 

Robot certificates are X.509 certificates granted to a portal service or application, 
rather than a human; users interested in running a certain application on the Grid can 
log in to the portal, and the portal will operate on the Grid using the robot certificate. 
This approach a few drawbacks: 

1 . The certificate private key is available on the portal machine, although this 
can be prevented by using hardware-based protection (e.g. smartcards), as 
done in the GILD A/GENIUS portal [3|. Indeed, guidelines |9| have been 
issued by the llGTFI on the generation and storage of private keys, and per- 
missible key usage of automated clients (robots) that can hold credentials 
issued bv llGTFf accredited Certification Authorities, so this specific issue is 
likely to become less relevant in the future. 

2. The use of robot certificates moves the responsibility of user authentica- 
tion and logging from the lCAI to the portal, thus implicitly introducing an 
additional trust step in the Grid authentication infrastructure. Not all Grid 
sites and resource providers might be happy with delegating trust this way. 

3. It is difficult to provide per-user accounting of computational resource us- 
age: jobs submitted through different interfaces (e.g., portal and command- 
line) by the same user will be accounted to different end-entities, since all 
popular Grid middlewares group usage records by certificate subject Dis- 
tinguished Name ( IDND . 
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The solution adopted in the P-GRADE portal IflOl l23l is to have users upload a 
long-lived proxy to a MyProxy server ll32l 1331 125 1 and authorize the portal software 
for automated retrieval of short-lived proxies for job submission and data movement. 
However, this still requires users to deal with many of the complexities of manag- 
ing X.509-based certificates and command-line tools, which has been found to be a 
real barrier to Grid adoption in less tech-savvy user communities. In the newer WS- 
PGRADE portal [24] the interaction with the MyProxy service has been streamlined 
so no command-line interaction is necessary, user certificate can be directly uploaded. 
However, the user still needs to apply for and manage a certificate that expires every 
year. For the end-user it is a complication to use an authentication infrastructure that 
does not blend with the native web portal authentication system. It interrupts the natu- 
ral flow of operations in the web user interface, requiring either an additional password 
(the certificate password to generate the proxy) or additional command-line operations 
in order to proceed with Grid job submission and control. 

An extension to this mechanism that blends more seamlessly with P-GRADE's 
web-based interface has been developed by the UK project SARoNGS in 1 14|. Click- 
ing a button on the MyProxy web details page redirects the user to a web service 
(Shibboleth-protected), which in turn loads a long-lived proxy into a specific MyProxy 
server, and fills in the details in the P-GRADE configuration page. 

The approach taken in GridCertLib, instead, requires no user interaction: once 
the web-based Shibboleth login is successfully completed, the GridCertLib code can 
generate an X.509 certificate through the [SLCS] service using the web service based lECPl 
delegation, and an accompanying Grid proxy. Details of this process are given in the 
following sections. 

The source code of GridCertLib is publicly available from |http : //gridcertlib . googlecode . com/] 
under the Apache License 2.0 J2)- 

3 Design and Implementation 

3.1 Architecture overview 

GridCertLib was designed to bridge Shibboleth-based and Grid X.509-based authenti- 
cation services for web applications and portalsQ Its design goals were to allow easy 
integration into any Java portal, and to minimize interaction with the user while retain- 
ing the full security stack for Grid authentication and authorization. 

The flow of interaction with the Java portal code and the SWITCHaai services il- 
lustrated in Figure 1 was devised in order to accomplish the design objectives (numbers 
in parentheses correspond to arrows in Figure[T]i: 

(1) Users initiates log in to the web portal using Shibboleth single sign-on (i.e., request 
a Shibboleth-protected URL). 

(2) They are authenticated by their home organization's identity provider lldPl this is 
handled transparently by the Shibboleth software^ 

2 Henceforth, we shall briefly write "portal" to mean any web-based interactive application or service. 

3 A detailed understanding of the Shibboleth authentication process is not needed for working with Grid- 
CertLib: it suffices to know that the outcome of a successful Shibboleth logon is a Security Assertion Markup 
Language version 2 ISAML2I assertion stored in the web server on the Portal machine. The interested reader 
is referred to [19 39 15] for an introduction to Shibboleth and lSAML2l 
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Figure 1: Interactions of GridCertLib with the other involved services. Components 
in the center column are all part of the same web application (but they could be part 
of different processes: for instance, the Shibboleth web login is usually handled by an 
Apache module rather than by Java servlet code). Round boxes on the sides represent 
services running on remote hosts, that GridCertLib interacts with over lHTTPl A detailed 
description of interactions is given in Section [3Tl 
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(3) GridCertLib queries Apache's mocLshib to get the ISAML21 assertion. The assertion 
is exported, together with other authentication parameters, to any proxied web ser- 
vice; portals may make use of these Shibboleth attributes to restrict certain services 
or map users into user groups. 

(4) The portal application code calls GridCertLib to obtain a short-lived Grid X.509 
certificate signed by the ISLCSICAI This step requires delegation of the Shibboleth 
credentials ( ISAML2I assertion) to the lSLCSI login service, which is done through the 
generic Identity Domain - Web Service Framework OID-WSFD IECPI Web Service 
Client, developed by SWITCH ll42l . 

(5) After logging in to the ISLCSI service. GridCertLib proceeds to generate an X.509 
certificate and have it signed by the ISLCSI online IcaI using code similar to the one 
used by gLite's slcs-init command-line client [43 1. 

(6) The portal calls GridCertLib to create a grid proxy (with or without [VOMS] exten- 
sions). Here GridCertLib is just a thin wrapper around the regular IvOMSI libraries. 
mainly providing simpler facade calls for commonly-used cases. 

(7) The certificate, private key and proxies are stored. Currently, GridCertLib provides 
methods for persisting certificates and proxies to the filesystem; it is up to the portal 
to move the files to different storage back-ends (e.g., databases), although it should 
be noted that most Grid middlewares require the proxy to be in a known location 
on the filesystem. 

As soon as the GridCertLib code completes successfully, a valid certificate and 
proxy are available on the filesystem and Grid operations can proceed. 

The foreseen usage of GridCertLib in web portals (see Section |Deployment Experiences) ) 
called for implementation of additional features in GridCertLib: 

a. The ISLCSl and the Grid/VOMS proxy generation functions can be called 
independently. In particular, proxy generation does not rely on the ISLCSI 
generation feature being called first. As a consequence, Grid proxy code 
does not need Shibboleth authentication to run, it only expects a valid user 
certificate to be available. 

This is a portal user interface requirement: all that is necessary for gener- 
ating an X.509 certificate is known after lSLCSl login. but proxy generation 
requires additional data; namely, names of the VOs a user belongs to. Por- 
tals might need to gather this additional data after a user has logged in. 

b. The ISLCSI generation function can be called at any time, as long as the 
ISAML2l assertion resulting from the Shibboleth login process is available. 

This is another portal user interface requirement: ISLCSI login and genera- 
tion of X.509 certificates can take long times (from a user interface per- 
spective), so they can be delayed at a later stage or started in an asyn- 
chronous thread, in order not to delay the login process. 

c. GridCertLib has a generic interface that can be used with any web appli- 
cation or portal. In particular, GridCertLib does not make any assumption 
on how user data (like the certificates) are represented and/or stored within 
the portal, except that they can be stored on the filesystem. 
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Feature a. led us to provide GridCertLib with two main independent entry points, 
SLCSFactory and GridProxyFactory. An instance of each class is responsible for gen- 
erating [SLCS]certific ate and Grid proxies, respectively. To achieve portal independence, 
each class constructor takes an explicit list of all the parameters needed for instan- 
tiation, although they can also be conveniently provided by a single Java Properties 
object. 

Similarly, for the same goal c. of portal technology independence, GridCertLib 
certificate and proxy generation functions accept an explicit list of all the required 
parameters, but provide shortened forms that have common defaults. 

Feature b. implies that the ISLCSh generation methods in GridCertLib only require 
the Shibboleth lSAMLI assertion as input. However, the ISAML21 assertion can expire long 
before the Shibboleth session itself does (see Section [3. 2. II ). To solve this problem, 
GridCertLib provides a re-usable servlet lRenewAssertionl which can also be used as a 
model for implementing assertion renewal in the portal code. 

3.2 Core Library Implementation 

GridCertLib core functions reside in the single Java package ch . swing . gridcertlib; 
an additional package ch. swing. gridcertlib. servlet provides example servlets 
(with fully-commented code) that show how the library can be used. 

The main package ch. swing. gridcertlib has two public entry points: 

• The SLCSFactory class provides the lSLCSI certificate generation functionality and 
can store the certificate and its associated private key on the filesystem. 

• The GridProxyFactory class creates Globus Toolkit proxy certificates with or 
without IVOMSI extensions from available user certificates and stores them to a 
temporary location on the filesystem. 

A single instance of each of these classes can generate multiple ISLCSI certificates 
or proxies, possibly for different Portal users, via repeated invocation of the certificate 
creation methods. 

Since the parameters used to configure the factory objects are portal-wide global 
variables and their values are fixed while the portal application is running, each factory 
class can be configured (at construction time) through a java.util. Properties object, 
which can be conveniently loaded from a file with standard Java lAPll calls. Alternatively, 
a constructor that allows to specify all instance parameters explicitly is also provided. 

However, GridCertLib does not enforce that only a single instance of these factory 
objects exists. Different factory objects can be created to cater for different classes of 
users (e.g., users coming from different Shibboleth federations). It is up to the web 
application/portal code to route requests to the correct factory. 

3.2.1 Creating SLCS Certificates 

Upon calling the newSLCS method of the SLCSFactory class, a SLCSRequestor object 
is created to carry out generation of the certificate and actual interaction with the ISLCSI 
server. The reason for this split is twofold: 

• SLCSFactory handles system-wide defaults, and thus a single instance is needed 
to serve the whole portal, whereas a new SLCSRequestor object is created for 
every certificate request. 
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• The SLCSRequestor corresponds to the slcs-init command-line tool provided 
in the gLite middleware distribution B31I ; this eases porting of fixes from the 
official [SLCSI client on to GridCertLib. 

ISLCSI certificates are created following these steps: 

1. Login to the ISLCSI server using ECPl delegation: if successful, this returns 
the subiect lDNl to use in the X.509 certificate to be generated, and an autho- 
rization token to validate the final certificate signing request to the same 
IslcsI server. 

2. Locally generate an X.509 public/private key pair. 

3. Locally generate an X.509 Certificate Signing Request ( ICSRD . using the 
subiect lDNl and other X.509 constraints returned by step 1. 

4. Submit the lCSRI to the ISLCSI server and get the signed certificate back. 

All of the above steps keep data (like the password), which is necessary for the 
private key, in memory. Only after a certificate has been successfully generated by the 
SLCSRequestor will SLCSFactory save the result in a file and return the certificate file 
path, private key path and private key password to the caller. Any of these three can be 
defined by the client code by passing an optional argument to the newSLCS method; 
by default, SLCSFactory uses a random password and stores the certificate and private 
key files in a configurable directory (using a random file name, which is also returned 
as a result of the call). 

The ISLCSl service is a properly authorized Shibboleth Service Provider flSPl l. Since 
GridCertLib is contacting ISLCSI on behalf of the user, and with no user intervention 
at all, delegation of ISAMLI credentials is needed. Shibboleth delegation is an experi- 
mental feature available in Shibboleth2, by which the ISAML21 assertion that initiates a 
Shibboleth session on an [SP] may be re-used to authenticate towards other web ser- 
vice based SPs. Shibboleth delegation must be supported both on the HdPI granting the 
ISAML2I assertion and the targetlSPlreceiving the delegated assertion (the lSLCSl server in 
this case). 

The requirement that lSLCS I generation may happen at any time after login to the por- 
tal creates an additional complication: ISAML2I assertions have a short time validity (5 
minutes in the default configuration) but IspI and HdPI sessions last much longer (8 hours 
by default), i.e., users are authenticated with the Shibboleth IspI even after the ISAML21 
assertion is long expired. Therefore, by the time SLCSFactory. newSLCS is called, the 
ISAML2I assertion might be unusable for delegated authentication with the ISLCSI server. 
There is no support in the Shibboleth IAPII to get a fresh assertion in the HdPI and store 
it in the [SP] session, but this can be worked around by forcing an [SP] session logout, 
followed by a redirection to a Shibboleth-protected IURLI the [SP] will start a new ses- 
sion and request a fresh assertion from the HdPI This can be implemented by a chain 
of IHTTPI redirections. so that the whole procedure does not require any user interven- 
tion. We implemented this workaround in the RenewAssertion servlet, described in 
Section |3~231 

3.2.2 Creating Grid and VOMS proxies 

The GridProxy Factory class is a interface wrapper on top of the I VOMSl Java lAPll Grid- 
ProxyFactory implements a simplified interface to create a Grid proxy in the use case 
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most frequently needed in web applications and portals: its newProxy method creates a 
proxy (with optional Tvoms I extensions) given an X.509 certificate and private key, and 
a (possibly empty) list of VOs to contact for lVOMSl ACs. 

A single instance of the class can generate multiple proxies (possibly for different 
users) via repeated invocation of the newProxy method. Since the org.glite.voms. con- 
tact. VOMSProxylnit class uses system properties to determine part of its configuration, 
it is not possible to create different instances of this class, each using its own config- 
uration. This is not a limit in practice, as the org.glite.voms library has native support 
for multiple servers and Virtual Organisation OVOD endpoints. 

3.2.3 Example servlets 

The provided sample servlets can run in any Java servlet container. They have been 
successfully tested with the Jetty and Tomcat Java application servers (with an Apache 
proxy front-end for managing the Shibboleth session). 

Three servlets are distributed with the GridCertLib source code: 

• Slcslnit: This servlet generates an X.509 certificate and private key and uses the 
ISLCSI service to sign it. Upon successful completion, the certificate and private 
key are stored in the filesystem. 

• VomsProxylnit: This servlet creates a lVOMSl proxv and stores it in the filesystem. 

• RenewAssertion: This servlet ensures that a fresh IS AMLl assertion is stored in the 
IspI Shibboleth session cache. 

A detailed description of each of these servlets follows. 

Slcslnit. The ch.swing.gridcertlib. servlet. Slcslnit servlet extracts the lSAML2l assertion 
lURLI from the Shibboleth lHTTPI headers. downloads the assertion into memory, and uses 
it to authenticate to a remote lSLCSI service and get a new certificate/private key pair. The 
key is encrypted with a random password, and the certificate and private key locations 
(on the filesystem) are printed in the response text. 

If SLCSFactory detects an expired assertion in the [SP] session, it will raise an ex- 
ception. The Slcslnit code catches the error and redirects the user's browser to the 
IRenew Assertionl servlet. setting the return address to the current page: when the user 
browser is sent back to the return ITJRLl a new ISAML21 assertion will be in thelSPlcache. 

VomsProxylnit. The ch.swing.gridcertlib. servlet.VomsProxylnit servlet creates a lVOMSI 
proxy and stores it on the filesystem, in the default store directory. IHTTPI querv parame- 
ters can set arguments that are passed to the GridProxyFactory.newProxy method, thus 
making this servlet a generic front-end to the GridProxyFactory class functionality. 

This servlet does not require any interaction with the Shibboleth subsystem, and 
can be deployed unprotected. It requires, however, that the certificate and private key 
are available on the filesystem. 

RenewAssertion. The ch.swing.gridcertlib.servlet.RenewAssertion servlet ensures that 
a fresh assertion is stored in the[SP]Shibboleth session cache. It implements the workaround 
described in a previous section for the "expired assertion" problem: 

1. The user's browser is redirected to the [SP] session logout lURLl 
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2. The logout function allows setting a "return address" via a [URL] query pa- 
rameter, to which the browser will be redirected after the logout is done; 
this "return address" is set to the Renew Assertion lURLl plus a trailing com- 
ponent OURLI "path information" part) that encodes the referring page lURLl 

3. The Shibboleth[SP]logs the user out of the session and destroys the cached 
data, then redirects the user browser to the Rene\vAssertion \URL\ 

4. The RenewAssertion page is Shibboleth-protected, so a new Shibboleth 
authentication procedure begins. As long as the user session in the UdPl is 
still valid, this will not require user interaction, and the HdPI will just send a 
new ISAML21 assertion to the requestinglSPl 

5. The RenewAssertion servlet detects that the browser is returning after the 
initial visit (from the trailing portion of the IURLD . and redirects the user 
to the initial requesting page (by decoding the IURLI embedded in the "path 
information" component). 

Note that none of the above steps requires any user interaction (unless the Shibbo- 
leth session on the lldPl is expired). 

A request IURLI to RenewAssertion must be properly formatted; the convenience 
method RenewAsse rtion.getRenewalUrl is provided to this purpose. However, the IURLI 
encoding system in the RenewAssertion servlet imposes a limit on the length of return 
URLs; more importantly, it cannot be used with IHTTPl POST requests, as there is no 
way of encoding the POST data into a single IURLI This is a technical issue which 
we have not been able to work around so far: due to the large number of [HTTP] redi- 
rects taking place, session cookies, query parameters, and other commonly-used ways 
of associating state data with IHTTPl requests, may be lost before the final visit to the 
RenewAssertion servlet. 

4 Deployment experiences 

The following points need to be taken into consideration by the portal providers: 

• Since certificate generation can be time-consuming (relative to user interface 
reaction times), it could be delayed to a later stage or executed asynchronously 
in a separate thread. However, this delay was not a problem on the P-GRADE 
Bioinformatics portal. 

• The validity of the Shibboleth assertion is usually limited to a few minutes, so 
the ISLCSI certificate request should not be delayed for too long. Of course if a 
valid ISLCSl certificate for the user is already available from a previous login of 
the user, the request can simply be omitted. 

• When a lVOMSl enabled proxy is needed, it is the portal's responsibility to prompt 
the user for the relevant information, e.g,. IVOI name or Fully-Qualified Attribute 
Name QFQANp list. In the P-GRADE implementation, the users can set their 
VOs in their settings page. There is a global default configuration option for the 
administrator if every user is expected to be always member of the same lVOI 
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4.1 Integration into the P-GRADE portal 



The P-GRADE portal comes with full Grid X.509 proxy support, which in this case is 
a mixed blessing as many of the certificate management features need to be modified in 
various places of the portal code. Out of the box, P-GRADE supports proxy certificate 
upload or the usage of a MyProxy server to which the user has to upload the certificate 
outside of P-GRADE. 

In its standard form, P-GRADE provides no facilities for the creation of the certifi- 
cates; this is a new feature we add using GridCertLib. We extended the Shibboleth- 
enabled login ll29ll for the Gridsphere portal [13] (provided by the Australian MAMS 
project [28]) by storing all Shibboleth attributes including the assertion and other at- 
tributes that were not previously requested into a singleton object. 

In the MAMS implementation, on first-time login using Shibboleth, the user is 
presented with a registration request portlet which simply displays the attributes of the 
user as received through the Shibboleth login by the server. Users can then simply press 
a button "Send registration request", which triggers an email to the portal administrator, 
who can decide whether to enable the user account, and optionally assign it certain roles 
in Gridsphere. 

Users can simply reload the page or re-login once the admin has enabled them. At 
the same time it is checked whether an ISLCSI certificate still exists for the given user and 
whether it is valid for longer than 24 hours. If not, GridCertLib is used to create a new 
ISLCSI certificate. The certificate location and other related information is stored together 
with all other user attributes in the user table, which has been extended accordingly. 

The lVOMSl configuration is the same for all users of the portal in our current imple- 
mentation, which is set to the "life" IVOI of the national grid computing infrastructure 
Swiss Multi-Science Computing Grid (ISMSCGD |36|, using a portal-wide configuration 
of GridCertLib. 

An issue remains: the delegation feature used by GridCertLib is not yet deployed as 
a standard feature in the Swiss SWITCHaai federation, therefore we currently can only 
make use of this whole mechanism through a special home organization, the Virtual 
Home Organisation (IVHOD . provided by SWITCH for collaboration purposes. We have 
a dedicated group in the IVHOI where we can administer our own users. This should 
not be necessary anymore after the SWITCHaai federation has upgraded to a version 
of Shibboleth that supports delegation, which should happen sometime in late 201 1 or 
2012. 

For now, in the optimal case a user can log in through lAAll bv selecting the IVHOI as 
the "home organization", and is ready to submit Grid jobs to the Swiss Multi-Science 
Computing Grid. Clicking on the "Certificates" tab will show the details of the current 
certificates and their validity. 

Expiration of the certificate is not an issue, as P-GRADE requests the download 
of the results only when the user asks for it through the portal. The portal makes sure 
that a new proxy is generated automatically in the background from the ISLCS I certificate 
(if the existing proxy is not valid anymore). Should the ISLCSI certificate expire, a new 
one is requested automatically at the next login, so unless the user is actively using the 
portal browser window for 10 days with no interruption, this will not happen. 

4.2 Integration into Django-based web applications 

Django [8 1 is a high-level Python Web framework, providing reusable components 
to build any sort of web application. We have used it to build a simple portal for 
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users of the computational chemistry application GAMESS-US 051 [121 . The por- 
tal uses the django-shibboleth application^ BTl to enable users to log in using their 
SWITCHaai/Shibboleth credentials; new users will have their account created auto- 
matically when they log in for the first time. 

Django support in GridCertLib thus comprises two (inter-dependent) parts: 

• A Python package, containing the access-control decorator^] certificate .required 
and gridproxy ^required. By using these decorators, a Django programmer can 
easily mark some URLs as requiring the use of a valid ISLCSI certificate and/or 
proxy. 

• A set of Java servlets, which should be deployed alongside the Django site, that 
interface with GridCertLib to provide the SLCS- and proxy-generation function- 
ality. 

All communication between the Django decorators and the corresponding servlets hap- 
pens by means of IHTTPI redirects through the users' web browser. 

The GridCertLib Django decorators will first ensure that the lHTTPl request is authen- 
ticated with the standard Django login system; when the django-shibboleth application 
is installed, this automatically ensures that the lHTTPl request is part of a valid Shibboleth 
session. 

Next, GridCertLib Django decorators check that the certificate (resp. proxy certifi- 
cate) exists and is valid. For the sake of processing speed (no response can be sent to the 
web browser until the decorator has passed control to the view function), the decorators 
assume that no other actor can modify the certificate/proxy files they have created: thus 
a simple "modification time" check suffices to prove that a certificate/proxy is still in 
its validity period. Note that, in contrast to what happens in the P-GRADE portal, the 
certificate/proxy check happens each time the Django view function is invoked, and it 
is thus essential to keep it performant. 

If the certificate/proxy exists and is valid, environment variables are set to the 
filesystem path of the relevant files to communicate the location to the Grid middle- 
ware, and control is passed to the view function. 

Otherwise, an IHTTPI redirect response is issued, channeling the web browser to the 
lURLl corresponding to a Django-specific version \SlcsInit\ oi\VomsProxyIn it servlets. As 



mentioned for the Example Servlets (see Section |3. 2. 31 >. only the \SlcsInit\ lJKL needs 
to be Shibboleth-protected. 

IHTTPI session cookies are used to tell the servlets to store the certificate/proxy in a 
certain filesystem location!! however this poses a mild security threat: since the servlets 
URLs must be public (so that the users' web browsers can visit them), then an IHTTPI 
request could be crafted to make the servlets read/write the certificate/proxy file in an 
arbitrary location on the filesystem. Security is enforced with the following procedure: 



4 Django structures a web site as an set of web applications, each of which is attached to specific URLs 
in the web site lURLI space. Applications can be packaged and deployed separately, and can be thus re-used 
in different combinations to build a site. 

5 Django routes lHTTPI requests to Python functions ("view" functions), that are responsible for returning 
content to the user. Access control is most easily done through Python function decorators: if a view function 
is marked with the loginjrequired decorator, then Django ensures that lHTTPl requests to that lURLl come from 
logged-in users, and will redirect any unauthorized request to the site login page. 

6 Since the \SksImt\ and \VomsPmxyInit\ servlets run in a Java server, completely separated by the server 
running Django, an issue arises as how to communicate certificate/proxy location and passphrases back and 
forth from the Django decorator to the Java servlets. 
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• Before starting the redirect to the a servlet, the Django access decorator creates 
an empty directory L, creates a "marker" file in it, and writes a random string K 
into this "marker" file. 

• The decorator redirects the web browser to the servlet lURLl passing along L and 
K (as lHTTPl cookies). 

• The servlet verifies that the "marker" file exists in L and that it has the expected 
content K, then it deletes the "marker" file and proceeds. For added security, it 
can optionally verify that L is a filesystem path starting with a configured prefix 
(e.g., /var /www/portal), so that possible damage is confined to a portion of the 
filesystem. 

It is clear that the above procedure guarantees that hypothetical attackers can only trick 
the GridCertLib servlets into writing into a location L if and only if they can already 
write to L. 

The added security layer is basically the only difference between the Django- 
support servlets and the GridCertLib example servlets (see Section [3.2.3b . After suc- 
cessful creation of the certificate or proxy, the servlet redirects the web browser back 
to the initial requesting page with no output. 

As in the P-GRADE integration, two issues remain that might need special attention 
in the future: 

• The IVOMSl configuration is the same for all users: while it is possible to extend 
the Django user object model to include individual IVOMSl information, this is 
not necessary at present since all users of the [GAMESS] portal belong to the same 
Virtual Organization. 

• Until the delegation feature becomes a standard feature of SWITCHaai, users 
have to select the special home organization lVHOl in order to use the portal. 

Django support for GridCertLib provides an example of how GridCertLib can be 
integrated into an existing web framework with little coding and only small edits to tune 
the example servlet behavior to the interface expected by other portal components. 

5 Conclusions and Future Developments 

GridCertLib is an easy to use Java library that enables automatic creation of lSLCSI cer- 
tificates and/or Grid proxies from ISAML2I assertions obtained from successful Shib- 
boleth authentication. It can be integrated into real-world Grid portals, hiding the 
complexities of X.509 certificate usage from the portal user. This considerably low- 
ers the barrier to Grid usage, potentially allowing much larger communities to profit 
from Grid resources securely. Source code for GridCertLib is publicly available from 
|http : //gridcertlib . googlecode . com/| under the Apache License version 2.0 [2|. 

The current implementation of GridCertLib relies on three key features of the 
SWITCHaai infrastructure: Shibboleth authentication. HD-WSFIECPI delegation. and the 
ISLCSI online lCAI service. The integration of these three components together with a valid 
access to a IVOMSl server, allow the creation of any community-specific web portal that 
can leverage the national grid computing infrastructure ISMSCGl 1 36 1 thus enabling Grid 
use by virtually any Swiss scientific community. 

An interesting future development could be to adapt GridCertLib to draw certifi- 
cates from the (recently created) IT ERENAl on-line IcaI this would lift the dependency on 
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the Swiss infrastructure and potentially allow usage of GridCertLib on any European 
Grid infrastructure. 

More generally, one could investigate whether GridCertLib could be ported to pro- 
vide its functionality on top of equivalent base technologies (e.g., substitute Shibboleth 
with a different lSAMLI -based federated authentication infrastructure). Developments in 
this area could turn GridCertLib into a modular system capable of providing its func- 
tionality for almost all Grid users today. No investigation has been carried out by us 
in this area: the project that funded GridCertLib development had a practical scope 
of producing a simple single sign-on solution for the selected portals; we are anyway 
open to collaborations in this respect. 

GridCertLib has already been successfully deployed and integrated into a Bioinfor- 
matics portal based on P-GRADE, and into a Django-based Computational Chemistry 
portal, proving the flexibility and re-usability of the library and its design. 

We will assist in the integration of GridCertLib into portals that are in use in 
Switzerland, like JOpera ED and the new WS-PGRADE |22|. We will consider re- 
quests for extensions in functionality of the GridCertLib based on the experience with 
these new portals. 

Looking further into the future, GridCertLib will greatly profit from the upgrade 
of the SWITCHaai federation to the next version of Shibboleth: this will enable true 
single-sign on and Grid usage in one portal, without the need to use a special [VHO] ac- 
count. The SystemsX project SyBIT [41 1 also plans to upgrade its P-GRADE portal 
from the current Gridsphere-based implementation to the more modern WS-PGRADE, 
which makes use of the Liferay portal [26 1 technology: besides many portal-related im- 
provements, this will allow the users to freely choose the lVOMSl attributes they wish to 
associate with their proxy. However, due to the entirely new portal code base, a new 
programming effort will be needed to integrate GridCertLib into the Liferay frame- 
work. 
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List of acronyms 



AAI 



Authentication and Authorization Infrastructure 



AC 



Attribute Certificate (VOMS, X.509) 



API 



Application Programming Interface 



CA 



Certification Authority 



CSR 



Certificate Signing Request 



DN 



Distinguished Name 
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ECP Enhanced Client or Proxy 

EGEE Enabling Grids for E-sciencE 

FQAN Fully-Qualified Attribute Name (VOMS) 

GAMESS General Atomic and Molecular Electronic Structure System, a 
Computational Chemistry application (see Il35l[l2l0 

GC3 Grid Computing Competence Center, University of Zurich 

HTTP HyperText Transfer Protocol 

ID-WSF Identity Domain - Web Service Framework (Shibboleth) 

IGTF International Grid Trust Federation 

idP Identity Provider (Shibboleth) 

MAMS Meta Access Management System, an Australian development project 
(see J28)) 

PKI Private Key Infrastructure 

SAML Security Assertion Markup Language 

SAML2 Security Assertion Markup Language version 2 

SARoNGS UK development project (see [20|) 

SLCS Short-Lived Credential Service 

SMSCG Swiss Multi-Science Computing Grid 

SP Service Provider (Shibboleth) 

SSO Single Sign-On 

SWITCH Swiss Academic Network Provider 

TERENA Trans-European Research and Education Networking Association 

URL Uniform Resource Locator 

VHO Virtual Home Organisation 

VOMS Virtual Organisation Membership Service 

VO Virtual Organisation 

XACML extensible Access Control Markup Language 
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